Prior to the arrival and adoption of the World Wide Web or Internet, the development of sophisticated client-server applications was generally a skill undertaken by highly skilled software developers. With the introduction of the Internet, along with open standards such as HTML and the plethora of tools available for web page developers, this high level of skill has become unnecessary, at least on the client-side. In the era of the Web, graphic artists and other parties are readily able to construct the client-side of a web site or an entry-level web-based application, the software engineers and developers relegated to the role of designing and developing the server-side business logic and architectures.
The current paradigm, then, involves relatively low-cost resources developing the client-side of Internet offerings, and more expensive professional software engineers designing and developing the server-side components. In recent times, particularly as companies and organisations have concentrated on migrating large-scale enterprise applications to the Internet, a number of problems have become apparent. These include poor performance, particularly in the low bandwidth arena, and lack of client-side robustness, due to the inherent inefficiencies of HTML as an application mark-up language.
With respect to the use of HTML, there is generally very limited capability to create ‘windows-style’ or rich multi-display GUI applications, particularly with densely compacted component layouts. In addition, the lack of intrinsic browser-based client-side intelligence tends to force the majority of the processing activity onto the server, resulting in a very high level of browser-client-Web-Server interaction, particularly when compared with the client-server predecessors. This can lead to real problems in low bandwidth environments.
HTML was designed with document publication in mind, so HTML applications largely lack the user interface functionality of conventional client-server applications (multiple windows, drag-and-drop capabilities, spreadsheet features, etc). Generally speaking, of course, HTML applications require a new page to be served at each user interaction, each page occupying a large footprint. All this leads to significant disadvantages in terms of user productivity. The addition of client-side scripting languages, such as Java Script and ActiveX, have helped offload some server-side processing to the client, but have not addressed problems in layout around the Document Object Model (DOM) where HTML remains the layout backbone. Moreover, data transfer between the browser-based client and the web server are not compressed, resulting in far greater data transfer requirements than the client-server predecessors (again, a problem in low bandwidth environments).
A number of the drawbacks referred to above, and in particular the volume of information transfer between the web server and the client, are related to the need, at each service request, for the entire client to be reloaded, including all of the client's layout information. HTML, of course, is essentially a single-display model, in contrast to traditional multi-display client-server applications.
The drawbacks discussed above can have a particularly acute impact in the Internet-based, wireless environment, due to the necessary resource limitations in terms of memory, bandwidth and operating/file systems
In the traditional thin client development model, for each application subset each set of main classes and window specific classes is different. Each subset must be separately developed and tested, and must then be loaded separately. As total business applications require many different application subsets, this can lead to high bandwidth requirements or poor performance. The more display components or windows in an application subset—with the associated business logic and event handling code for each component or window—the greater the overall size of the specific client.
Some recent developments have led to improvement in the situation. However, web-based client-side Java-based applications developed have still tended to involve essentially fat clients, which become fatter still as new functionality and features are added. This relegates the use of sophisticated client-side Java-based application to the realm of high-bandwidth environments.
The present invention seeks to address at least some of the problems referred to above.